Electronic systems are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating these electronic system typically involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of electronic system, its complexity, the design team, and the electronic system fabricator or foundry that will manufacture the electronic system. Typically, software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators, and errors in the design are corrected or the design is otherwise improved.
Several steps are common to most design flows for electronic system. Initially, the specification for a new circuit is transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the circuit. With this logical design, the circuit can be described in terms of both the exchange of signals between hardware registers and the logical operations that can be performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as the Very high speed integrated circuit Hardware Design Language (VHDL). The logic of the circuit is then analyzed, to confirm that it will accurately perform the functions desired for the circuit. This analysis is sometimes referred to as “functional verification.”
Functional verification typically begins with a circuit design coded at the register transfer level, which can be simulated, emulated, formally verified, or the like, by one or more design verification tools. For example, a designer can generate a test bench that, when simulated or emulated with the circuit design, can allow the design verification tool to analyze the functionality of the simulated or emulated circuit design. When the simulated circuit design operates differently than expected in response to stimulus from the test bench, the designer can attempt to debug the circuit design, for example, to determine which of portions of the circuit design is incorrectly configured, resulting in the generation of illegal states or transitions.
The design verification tool can also attempt to identify how well verification operations, such as simulation, emulation, and/or formal verification, came to covering or adequately exercising the circuit design under verification. Conventional techniques to determine coverage of the circuit design include code coverage and functional coverage. Code coverage, such as statement coverage, branch coverage, decision coverage, condition coverage, expression coverage, toggle coverage, or the like, can identify which lines, statements, expressions, decisions, or toggles of the circuit design were exercised by the test bench during verification operations. Functional coverage can quantify how well a circuit design had its functionality exercised during verification operations.
The design verification tools can collect coverage data during verification operations and record the coverage data into one or more databases based on a coverage data model. Most vendors of these design verification tools utilize a common coverage data model to store coverage data from their own design verification tools, but different vendors often utilize different coverage data models.
A Unified Coverage Interoperability Standard (UCIS) was created to help alleviate this lack of vendor-to-vendor interoperability of coverage data caused by diverse coverage data models. The UCIS defines features a coverage data model is to include in order to be standard-compatible, and also includes recommendations for the coverage data models, for example, with the scope and coveritem building blocks plus attributes and flags. Since the UCIS allows multiple different types of coverage data models to be UCIS-compliant, most of the time, different coverage databases are not binary compatible. As such, the UCIS also defined an exchange format to facilitate transfers or exchanges of coverage data between databases implementing UCIS-compliant, yet differing, coverage data models.
The UCIS utilizes Extensible Markup Language (XML) as the exchange format, which can allow vendors to output coverage data in an XML file and input coverage data in an XML file. While the use of XML as an exchange format can allow for transfers of coverage data between databases having different coverage data models, there are some non-overlapping inconsistencies between an internal coverage data representation of the UCIS and an internal coverage data representation of the XML format. This inconsistency means the UCIS can include coverage data not defined by the XML internal coverage data representation and vice versa. The use of XML for the exchange format of UCIS coverage data can also be verbose, as XML files including the coverage data from a UCIS-compliant database can be hundreds of times larger than the binary representation of the coverage data in the UCIS-compliant database. While XML files may be compressed to reduce this size disparity, compression of the XML file takes time, consumes processing resources, and results in generating compressed XML files that still remain multiple times larger than the binary representation of the coverage data from the UCIS-compliant database.